Nodrošiniet drošu un netraucētu lietotāju autentifikāciju ar OAuth2. Šis ceļvedis sniedz detalizētu pārskatu par OAuth2 ieviešanu trešo pušu piekļuvei.
OAuth2 ieviešana: visaptverošs ceļvedis trešo pušu autentifikācijai
Mūsdienu savstarpēji savienotajā digitālajā vidē netraucēta un droša lietotāju autentifikācija ir vissvarīgākā. OAuth2 ir kļuvis par nozares standarta protokolu, lai ļautu trešo pušu lietojumprogrammām piekļūt lietotāju resursiem citā pakalpojumā, neizpaužot viņu akreditācijas datus. Šis visaptverošais ceļvedis iedziļinās OAuth2 ieviešanas smalkumos, sniedzot izstrādātājiem zināšanas un praktiskus norādījumus, kas nepieciešami, lai integrētu šo jaudīgo autorizācijas sistēmu savās lietojumprogrammās.
Kas ir OAuth2?
OAuth2 (Open Authorization) ir autorizācijas sistēma, kas ļauj trešās puses lietojumprogrammai iegūt ierobežotu piekļuvi HTTP pakalpojumam lietotāja vārdā, vai nu organizējot lietotāja apstiprinājumu, vai arī ļaujot trešās puses lietojumprogrammai iegūt piekļuvi savā vārdā. OAuth2 koncentrējas uz klienta izstrādātāju vienkāršību, vienlaikus nodrošinot konkrētas autorizācijas plūsmas tīmekļa lietojumprogrammām, darbvirsmas lietojumprogrammām, mobilajiem tālruņiem un viesistabas ierīcēm.
Padomājiet par to kā par autostāvvietu. Jūs nododat savas automašīnas atslēgas (akreditācijas datus) uzticamam novietotājam (trešās puses lietojumprogrammai), lai viņš varētu novietot jūsu automašīnu (piekļūt jūsu resursiem) bez jums tieši piešķirot piekļuvi visam pārējam jūsu automašīnā. Jūs saglabājat kontroli un vienmēr varat atgūt savas atslēgas (atsaukt piekļuvi).
Galvenie OAuth2 koncepcijas
Izpratne par OAuth2 pamatkoncepcijām ir būtiska veiksmīgai ieviešanai:
- Resursu īpašnieks: Vienība, kas spēj piešķirt piekļuvi aizsargātam resursam. Parasti tas ir galalietotājs.
- Resursu serveris: Serveris, kurā atrodas aizsargātie resursi, kas pieņem un reaģē uz aizsargātu resursu pieprasījumiem, izmantojot piekļuves marķierus.
- Klienta lietojumprogramma: Lietojumprogramma, kas pieprasa piekļuvi aizsargātiem resursiem resursa īpašnieka vārdā. Tā var būt tīmekļa lietojumprogramma, mobilā lietotne vai darbvirsmas lietojumprogramma.
- Autorizācijas serveris: Serveris, kas izsniedz piekļuves marķierus klienta lietojumprogrammai pēc resursa īpašnieka veiksmīgas autentifikācijas un viņu autorizācijas iegūšanas.
- Piekļuves marķieris: Akreditācijas dati, kas apliecina resursa īpašnieka piešķirto autorizāciju klienta lietojumprogrammai. Klienta lietojumprogramma to izmanto, lai piekļūtu aizsargātiem resursiem resursu serverī. Piekļuves marķieriem parasti ir ierobežots darbības laiks.
- Atsvaidzināšanas marķieris: Akreditācijas dati, ko izmanto jauna piekļuves marķiera iegūšanai, neprasot resursa īpašniekam atkārtoti autorizēt klienta lietojumprogrammu. Atsvaidzināšanas marķieriem parasti ir ilgs derīguma termiņš, un tie ir droši jāuzglabā.
- Tvērums: Definē specifiskās atļaujas, kas piešķirtas klienta lietojumprogrammai. Piemēram, klienta lietojumprogrammai var piešķirt tikai lasīšanas piekļuvi lietotāja profilam, bet ne iespēju to modificēt.
OAuth2 piešķiršanas veidi
OAuth2 definē vairākus piešķiršanas veidus, katrs pielāgots konkrētiem lietošanas gadījumiem un drošības prasībām. Atbilstošā piešķiršanas veida izvēle ir ļoti svarīga, lai nodrošinātu drošu un lietotājam draudzīgu autentifikācijas pieredzi.
1. Autorizācijas koda piešķiršana
Autorizācijas koda piešķiršana ir visbiežāk izmantotais un ieteicamais piešķiršanas veids tīmekļa lietojumprogrammām. Tas ietver vairāku posmu procesu, kas nodrošina, ka klienta noslēpums nekad netiek atklāts resursa īpašnieka pārlūkprogrammai. Tas ir paredzēts konfidenciāliem klientiem (klientiem, kas spēj saglabāt sava klienta noslēpuma noslēpumu). Šeit ir vienkāršots sadalījums:
- Klienta lietojumprogramma novirza resursa īpašnieku uz autorizācijas serveri.
- Resursa īpašnieks autentificējas pie autorizācijas servera un piešķir atļauju klienta lietojumprogrammai.
- Autorizācijas serveris novirza resursa īpašnieku atpakaļ uz klienta lietojumprogrammu ar autorizācijas kodu.
- Klienta lietojumprogramma apmaina autorizācijas kodu pret piekļuves marķieri un atsvaidzināšanas marķieri.
- Klienta lietojumprogramma izmanto piekļuves marķieri, lai piekļūtu aizsargātiem resursiem resursu serverī.
Piemērs: Lietotājs vēlas savienot savu Google Drive kontu ar trešās puses dokumentu rediģēšanas lietojumprogrammu. Lietojumprogramma novirza lietotāju uz Google autentifikācijas lapu, kur viņš ienāk un piešķir lietojumprogrammai atļauju piekļūt viņa Google Drive failiem. Pēc tam Google novirza lietotāju atpakaļ uz lietojumprogrammu ar autorizācijas kodu, ko lietojumprogramma apmaina pret piekļuves marķieri un atsvaidzināšanas marķieri.
2. Neobligātā piešķiršana
Neobligātā piešķiršana ir vienkāršota autorizācijas koda piešķiršanas versija, kas paredzēta klienta lietojumprogrammām, kuras nevar droši uzglabāt klienta noslēpumu, piemēram, vienas lapas lietojumprogrammām (SPA), kas darbojas tīmekļa pārlūkprogrammā, vai vietējām mobilajām lietojumprogrammām. Šajā piešķiršanas veidā piekļuves marķieris tiek tieši atgriezts klienta lietojumprogrammai pēc tam, kad resursa īpašnieks ir autentificējies pie autorizācijas servera. Tomēr tas tiek uzskatīts par mazāk drošu nekā autorizācijas koda piešķiršana, jo pastāv piekļuves marķiera pārtveršanas risks.
Svarīga piezīme: Neobligātā piešķiršana pašlaik tiek uzskatīta par novecojušu. Drošības labākās prakses iesaka izmantot autorizācijas koda piešķiršanu ar PKCE (Proof Key for Code Exchange) vietā, pat SPA un vietējām lietotnēm.
3. Resursu īpašnieka paroles akreditācijas datu piešķiršana
Resursu īpašnieka paroles akreditācijas datu piešķiršana ļauj klienta lietojumprogrammai iegūt piekļuves marķieri, tieši nododot resursa īpašnieka lietotājvārdu un paroli autorizācijas serverim. Šis piešķiršanas veids jāizmanto tikai tad, ja klienta lietojumprogramma ir ļoti uzticama un tai ir tieša saikne ar resursa īpašnieku. Parasti tas tiek atturēts, ņemot vērā drošības riskus, kas saistīti ar akreditācijas datu tiešu kopīgošanu ar klienta lietojumprogrammu.
Piemērs: Bankas izstrādāta pirmās puses mobilā lietojumprogramma varētu izmantot šo piešķiršanas veidu, lai ļautu lietotājiem piekļūt saviem kontiem. Tomēr trešās puses lietojumprogrammām parasti vajadzētu izvairīties no šī piešķiršanas veida.
4. Klienta akreditācijas datu piešķiršana
Klienta akreditācijas datu piešķiršana ļauj klienta lietojumprogrammai iegūt piekļuves marķieri, izmantojot savus akreditācijas datus (klienta ID un klienta noslēpumu), nevis rīkojoties resursa īpašnieka vārdā. Šis piešķiršanas veids parasti tiek izmantots serveru savstarpējai saziņai vai tad, ja klienta lietojumprogrammai ir nepieciešams piekļūt tieši tās īpašumā esošajiem resursiem.
Piemērs: Uzraudzības lietojumprogramma, kurai nepieciešams piekļūt servera metrikai no mākoņu nodrošinātāja, varētu izmantot šo piešķiršanas veidu.
5. Atsvaidzināšanas marķiera piešķiršana
Atsvaidzināšanas marķiera piešķiršana ļauj klienta lietojumprogrammai iegūt jaunu piekļuves marķieri, izmantojot atsvaidzināšanas marķieri. Tas ļauj klienta lietojumprogrammai saglabāt piekļuvi aizsargātiem resursiem, neprasot resursa īpašniekam atkārtoti autorizēt lietojumprogrammu. Atsvaidzināšanas marķieris tiek apmainīts pret jaunu piekļuves marķieri un, iespējams, jaunu atsvaidzināšanas marķieri. Vecais piekļuves marķieris tiek nevalidēts.
OAuth2 ieviešana: soli pa solim ceļvedis
OAuth2 ieviešana ietver vairākus galvenos soļus:
1. Klienta lietojumprogrammas reģistrēšana
Pirmais solis ir klienta lietojumprogrammas reģistrēšana pie autorizācijas servera. Tas parasti ietver tādas informācijas sniegšanu kā lietojumprogrammas nosaukums, apraksts, novirzīšanas URI (kur autorizācijas serveris novirzīs resursa īpašnieku pēc autentifikācijas) un vēlamos piešķiršanas veidus. Pēc tam autorizācijas serveris izsniegs klienta ID un klienta noslēpumu, ko izmantos jūsu lietojumprogrammas identificēšanai un autentificēšanai.
Piemērs: Reģistrējot savu lietojumprogrammu ar Google OAuth2 pakalpojumu, jums būs jāsniedz novirzīšanas URI, kuram jāatbilst URI, ko jūsu lietojumprogramma izmantos, lai saņemtu autorizācijas kodu. Jums arī būs jānorāda tvērumi, kas nepieciešami jūsu lietojumprogrammai, piemēram, piekļuve Google Drive vai Gmail.
2. Autorizācijas plūsmas sākšana
Nākamais solis ir autorizācijas plūsmas sākšana. Tas ietver resursa īpašnieka novirzīšanu uz autorizācijas servera autorizācijas galapunktu. Autorizācijas galapunktam parasti būs nepieciešami šādi parametri:
client_id: Autorizācijas servera izsniegtais klienta ID.redirect_uri: URI, uz kuru autorizācijas serveris novirzīs resursa īpašnieku pēc autentifikācijas.response_type: Sagaidāmā atbildes veids no autorizācijas servera (piemēram,codeautorizācijas koda piešķiršanai).scope: Vēlamie piekļuves tvērumi.state: Neobligāts parametrs, ko izmanto, lai novērstu krusteniskās vietnes pieprasījumu viltošanas (CSRF) uzbrukumus.
Piemērs: Novirzīšanas URI varētu izskatīties šādi: https://example.com/oauth2/callback. state parametrs ir nejauši ģenerēta virkne, ko jūsu lietojumprogramma var izmantot, lai pārbaudītu, vai atbilde no autorizācijas servera ir likumīga.
3. Autorizācijas atbildes apstrāde
Pēc tam, kad resursa īpašnieks ir autentificējies pie autorizācijas servera un piešķīris atļauju klienta lietojumprogrammai, autorizācijas serveris novirzīs resursa īpašnieku atpakaļ uz klienta lietojumprogrammas novirzīšanas URI ar autorizācijas kodu (autorizācijas koda piešķiršanai) vai piekļuves marķieri (neobligātai piešķiršanai). Pēc tam klienta lietojumprogrammai jāapstrādā šī atbilde atbilstoši.
Piemērs: Ja autorizācijas serveris atgriež autorizācijas kodu, klienta lietojumprogrammai tas jāapmaina pret piekļuves marķieri un atsvaidzināšanas marķieri, veicot POST pieprasījumu uz autorizācijas servera marķiera galapunktu. Marķiera galapunktam parasti būs nepieciešami šādi parametri:
grant_type: Piešķiršanas veids (piemēram,authorization_code).code: No autorizācijas servera saņemtais autorizācijas kods.redirect_uri: Tas pats novirzīšanas URI, ko izmanto autorizācijas pieprasījumā.client_id: Autorizācijas servera izsniegtais klienta ID.client_secret: Autorizācijas servera izsniegtais klienta noslēpums (konfidenciāliem klientiem).
4. Aizsargāto resursu piekļuve
Kad klienta lietojumprogramma ir ieguvusi piekļuves marķieri, tā var to izmantot, lai piekļūtu aizsargātiem resursiem resursu serverī. Piekļuves marķieris parasti tiek iekļauts HTTP pieprasījuma Authorization galvenē, izmantojot Bearer shēmu.
Piemērs: Lai piekļūtu lietotāja profilam sociālo mediju platformā, klienta lietojumprogramma varētu veikt pieprasījumu šādi:
GET /api/v1/me HTTP/1.1
Host: api.example.com
Authorization: Bearer [access_token]
5. Marķiera atsvaidzināšanas apstrāde
Piekļuves marķieriem parasti ir ierobežots darbības laiks. Kad piekļuves marķieris beidzas, klienta lietojumprogramma var izmantot atsvaidzināšanas marķieri, lai iegūtu jaunu piekļuves marķieri, neprasot resursa īpašniekam atkārtoti autorizēt lietojumprogrammu. Lai atsvaidzinātu piekļuves marķieri, klienta lietojumprogramma veic POST pieprasījumu uz autorizācijas servera marķiera galapunktu ar šādiem parametriem:
grant_type: Piešķiršanas veids (piemēram,refresh_token).refresh_token: No autorizācijas servera saņemtais atsvaidzināšanas marķieris.client_id: Autorizācijas servera izsniegtais klienta ID.client_secret: Autorizācijas servera izsniegtais klienta noslēpums (konfidenciāliem klientiem).
Drošības apsvērumi
OAuth2 ir jaudīga autorizācijas sistēma, taču ir svarīgi to ieviest droši, lai aizsargātu lietotāju datus un novērstu uzbrukumus. Šeit ir daži galvenie drošības apsvērumi:
- Izmantojiet HTTPS: Viss saziņa starp klienta lietojumprogrammu, autorizācijas serveri un resursu serveri jāšifrē, izmantojot HTTPS, lai novērstu noklausīšanos.
- Pārbaudiet novirzīšanas URI: Rūpīgi pārbaudiet novirzīšanas URI, lai novērstu autorizācijas koda injekcijas uzbrukumus. Atļaujiet tikai reģistrētus novirzīšanas URI un pārliecinieties, ka tie ir pareizi formatēti.
- Aizsargājiet klienta noslēpumus: Saglabājiet klienta noslēpumus konfidenciāli. Nekad nesaglabājiet tos klienta pusē esošajā kodā un neizpaužiet tos neatļautām pusēm.
- Ieviesiet
stateparametru: Izmantojietstateparametru, lai novērstu CSRF uzbrukumus. - Pārbaudiet piekļuves marķierus: Resursu serverim ir jāpārbauda piekļuves marķieri pirms piekļuves piešķiršanas aizsargātiem resursiem. Tas parasti ietver marķiera paraksta un derīguma termiņa pārbaudi.
- Ieviešiet tvērumu: Izmantojiet tvērumus, lai ierobežotu klienta lietojumprogrammai piešķirtās atļaujas. Piešķiriet tikai nepieciešamās atļaujas.
- Marķieru glabāšana: Glabājiet marķierus droši. Vietējām lietojumprogrammām apsveriet operētājsistēmas drošo glabāšanas mehānismu izmantošanu. Tīmekļa lietojumprogrammām izmantojiet drošus sīkfailus vai servera pusē esošās sesijas.
- Apsveriet PKCE (Proof Key for Code Exchange): Lietojumprogrammām, kas nevar droši uzglabāt klienta noslēpumu (piemēram, SPA un vietējās lietotnes), izmantojiet PKCE, lai mazinātu autorizācijas koda pārtveršanas risku.
OpenID Connect (OIDC)
OpenID Connect (OIDC) ir autentifikācijas slānis, kas veidots virs OAuth2. Tas nodrošina standartizētu veidu, kā klienta lietojumprogrammas var pārbaudīt resursa īpašnieka identitāti, pamatojoties uz autorizācijas servera veiktās autentifikācijas datiem, kā arī iegūt pamatinformāciju par resursa īpašnieka profilu savstarpēji savietojamā un REST-līdzīgā veidā.
Kamēr OAuth2 galvenokārt ir autorizācijas sistēma, OIDC pievieno autentifikācijas komponentu, padarot to piemērotu lietošanas gadījumiem, kur jums ir nepieciešams ne tikai autorizēt piekļuvi resursiem, bet arī pārbaudīt lietotāja identitāti. OIDC ievieš ID marķiera koncepciju, kas ir JSON Web Token (JWT), kas satur apgalvojumus par lietotāja identitāti.
Ieviešot OIDC, atbilde no autorizācijas servera ietvers gan piekļuves marķieri (aizsargātu resursu piekļuvei), gan ID marķieri (lietotāja identitātes pārbaudei).
OAuth2 nodrošinātāja izvēle
Jūs varat vai nu ieviest savu OAuth2 autorizācijas serveri, vai izmantot trešās puses nodrošinātāju. Sava autorizācijas servera ieviešana var būt sarežģīta un laikietilpīga, taču tā dod jums pilnīgu kontroli pār autentifikācijas procesu. Trešās puses nodrošinātāja izmantošana bieži ir vienkāršāka un izmaksu ziņā efektīvāka, taču tas nozīmē paļauties uz trešo pusi autentifikācijai.
Populārākie OAuth2 nodrošinātāji ietver:
- Google Identity Platform
- Facebook Login
- Microsoft Azure Active Directory
- Auth0
- Okta
- Ping Identity
Izvēloties OAuth2 nodrošinātāju, apsveriet tādus faktorus kā:
- Cenas
- Funkcijas
- Drošība
- Uzticamība
- Integrācijas vienkāršība
- Atbilstības prasības (piemēram, GDPR, CCPA)
- Izstrādātāju atbalsts
OAuth2 dažādās vidēs
OAuth2 tiek izmantots plašā vidē klāstā, sākot no tīmekļa lietojumprogrammām un mobilajām lietotnēm līdz pat darbvirsmas lietojumprogrammām un IoT ierīcēm. Specifiskie ieviešanas nosacījumi var atšķirties atkarībā no vides, taču pamatkoncepcijas un principi paliek nemainīgi.
Tīmekļa lietojumprogrammas
Tīmekļa lietojumprogrammās OAuth2 parasti tiek ieviests, izmantojot autorizācijas koda piešķiršanu ar servera puses kodu, kas apstrādā marķieru apmaiņu un glabāšanu. Vienas lapas lietojumprogrammām (SPA) ieteicamā pieeja ir autorizācijas koda piešķiršana ar PKCE.
Mobilās lietojumprogrammas
Mobilajās lietojumprogrammās OAuth2 parasti tiek ieviests, izmantojot autorizācijas koda piešķiršanu ar PKCE vai vietējo SDK, ko nodrošina OAuth2 nodrošinātājs. Ir svarīgi droši uzglabāt piekļuves marķierus, izmantojot operētājsistēmas drošos glabāšanas mehānismus.
Darbvirzmas lietojumprogrammas
Darbvirzmas lietojumprogrammās OAuth2 var ieviest, izmantojot autorizācijas koda piešķiršanu ar iegultu pārlūkprogrammu vai sistēmas pārlūkprogrammu. Līdzīgi kā mobilajām lietojumprogrammām, ir svarīgi droši uzglabāt piekļuves marķierus.
IoT ierīces
IoT ierīcēs OAuth2 ieviešana var būt sarežģītāka ierobežoto resursu un šo ierīču drošības ierobežojumu dēļ. Atkarībā no specifiskajām prasībām var tikt izmantota klienta akreditācijas datu piešķiršana vai vienkāršota autorizācijas koda piešķiršanas versija.
Izplatītu OAuth2 problēmu novēršana
OAuth2 ieviešana dažkārt var būt sarežģīta. Šeit ir dažas izplatītas problēmas un to novēršanas veidi:
- Nederīgs novirzīšanas URI: Pārliecinieties, ka ar autorizācijas serveri reģistrētais novirzīšanas URI atbilst autorizācijas pieprasījumā izmantotajam URI.
- Nederīgs klienta ID vai noslēpums: Vēlreiz pārbaudiet, vai klienta ID un klienta noslēpums ir pareizi.
- Neautorizēts tvērums: Pārliecinieties, ka pieprasītie tvērumi tiek atbalstīti autorizācijas serverī un ka klienta lietojumprogrammai ir piešķirta atļauja tiem piekļūt.
- Piekļuves marķiera beigšanās: Izmantojiet atsvaidzināšanas marķieri, lai iegūtu jaunu piekļuves marķieri.
- Marķiera pārbaude neizdevās: Pārliecinieties, ka resursu serveris ir pareizi konfigurēts piekļuves marķieru pārbaudei.
- CORS kļūdas: Ja rodas krusteniskās izcelsmes resursu koplietošanas (CORS) kļūdas, pārliecinieties, ka autorizācijas serveris un resursu serveris ir pareizi konfigurēti, lai atļautu pieprasījumus no jūsu klienta lietojumprogrammas izcelsmes.
Secinājums
OAuth2 ir jaudīga un daudzpusīga autorizācijas sistēma, kas nodrošina drošu un netraucētu lietotāju autentifikāciju dažādām lietojumprogrammām. Izprotot pamatkoncepcijas, piešķiršanas veidus un drošības apsvērumus, izstrādātāji var efektīvi ieviest OAuth2, lai aizsargātu lietotāju datus un nodrošinātu lielisku lietotāju pieredzi.
Šis ceļvedis ir sniedzis visaptverošu pārskatu par OAuth2 ieviešanu. Atcerieties iepazīties ar oficiālajām OAuth2 specifikācijām un izvēlētā OAuth2 nodrošinātāja dokumentāciju, lai iegūtu sīkāku informāciju un norādījumus. Vienmēr piešķiriet prioritāti drošības labākajām praksēm un sekojiet līdzi jaunākajiem ieteikumiem, lai nodrošinātu lietotāju datu integritāti un konfidencialitāti.